Methods and computer-readable media for facilitating forensic investigations of online transactions

ABSTRACT

A method, comprising: receiving a first identifier associated with an online transaction and a second identifier used by end user equipment involved in the online transaction; obtaining evidentiary information pertaining to the end user equipment based on the second identifier; storing in a database a record that associates the first identifier with the evidentiary information; and retrieving one of (i) the evidentiary information in said record and (ii) the first identifier in response to a request identifying the other of (i) the evidentiary information in said record and (ii) the first identifier. Where the online transaction is effected over a network after the end user equipment has gained access thereto, the evidentiary information may include information pertaining to a subscriber whose credentials were used by the end user equipment to gain access to the network. The information pertaining to the subscriber may include personal information about the subscriber. Alternatively, the evidentiary information may include location information.

FIELD OF THE INVENTION

The present invention relates generally to online transactions and, moreparticularly, to methods and computer-readable media for maintainingrecords of online transactions so as to facilitate forensicinvestigations of such transactions.

BACKGROUND

While most transactions conducted online are genuine, there is a certainamount of fraud involving online transactions, and the ensuing financialloss suffered by merchants continues to increase annually. Also, thedistributed nature of the Internet tends to facilitate the availabilityof products or services whose procurement may in actual fact be illegaldue to the purchaser's age, location or other attribute. Whileinvestigations into possible fraud or illegality of a conventionaltransaction are straightforward, the same cannot be said about onlinetransactions where scarce data, if any, about the true individual whomade the transaction remains traceable after the fact.

Against this background, there is a need in the industry for solutionsfor maintaining records of online transactions that will facilitateforensic investigations of those transactions.

SUMMARY OF THE INVENTION

According to a first broad aspect, the present invention seeks toprovide a method, which comprises receiving a first identifierassociated with an online transaction and a second identifier used byend user equipment involved in the online transaction; obtainingevidentiary information pertaining to the end user equipment based onthe second identifier; storing in a database a record that associatesthe first identifier with the evidentiary information; and retrievingone of (i) the evidentiary information in said record and (ii) the firstidentifier in response to a request identifying the other of (i) theevidentiary information in said record and (ii) the first identifier.

According to a second broad aspect, the present invention seeks toprovide a computer-readable medium comprising computer-readable programcode which, when interpreted by a transaction management entity, causesthe transaction management entity to execute a method. Thecomputer-readable program code comprises first computer-readable programcode for causing the transaction management entity to be attentive toreceipt of a first identifier associated with an online transaction anda second identifier used by end user equipment involved in the onlinetransaction; second computer-readable program code for causing thetransaction management entity to obtain evidentiary informationpertaining to the end user equipment based on the second identifier;third computer-readable program code for causing the transactionmanagement entity to store in a database a record that associates thefirst identifier with the evidentiary information; and fourthcomputer-readable program code for causing the transaction managemententity to retrieve one of (i) the evidentiary information in said recordand (ii) the first identifier in response to a request identifying theother of (i) the evidentiary information in said record and (ii) thefirst identifier.

According to a third broad aspect, the present invention seeks toprovide a system comprising: a transaction record database comprising aplurality of records, each of said records relating a respective firstidentifier associated with an online transaction to respectiveevidentiary information pertaining to end user equipment involved in theonline transaction; and a transaction management entity configured torespond to a request identifying one of (i) a given first identifierassociated with a given online transaction and (ii) evidentiaryinformation related by one of said records to a given first identifierby retrieving the other of (i) the given first identifier and (ii) theevidentiary information related thereto.

According to a fourth broad aspect, the present invention seeks toprovide a method of investigating an online transaction associated witha transaction identifier. The method comprises providing the transactionidentifier to a transaction management entity; obtaining from thetransaction management entity evidentiary information pertaining to theend user equipment involved in the online transaction associated withthe transaction identifier; and comparing the evidentiary information toinformation associated with a transaction object used to effect theonline transaction.

According to a fifth broad aspect, the present invention seeks toprovide a method of identifying a suspect potentially responsible foreffecting an online transaction associated with a transactionidentifier. The method comprises providing the transaction identifier toa transaction management entity; obtaining from the transactionmanagement entity evidentiary information pertaining to the end userequipment involved in the online transaction associated with thetransaction identifier; and identifying as a suspect a party associatedwith the evidentiary information.

According to a sixth broad aspect, the present invention seeks toprovide a network entity for participating in an online transactiontaking place over a network. The network entity comprises a memory and aprocessing unit. The processing unit is configured to obtain atransaction identifier associated with an online transaction and alogical identifier associated with end user equipment involved in theonline transaction; store in said memory a record that relates saidtransaction identifier to said logical identifier; and transmit saidtransaction identifier and said logical identifier over the network toan entity responsible for storing a relationship between the transactionidentifier and evidentiary information pertaining to end user equipmentinvolved in said online transaction.

These and other aspects of the invention will become apparent to thoseof ordinary skill in the art upon review of the following description ofcertain embodiments of the invention in conjunction with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A detailed description of embodiments of the present invention isprovided herein below, by way of example only, with reference to theaccompanying drawings, in which:

FIG. 1 shows an architecture allowing a user of end user equipmentconnected to a packet-switched network to access and interact withmerchant sites of that network, for example, to make onlinetransactions, in accordance with an embodiment of the present invention.

FIG. 2A shows possible contents of a database that stores informationassociated with various logical identifiers assigned to various end userequipment used to access the packet-switched network shown in FIG. 1.

FIG. 2B shows possible contents of a transaction record database thatstores records for various transactions that have been attempted oreffected by various subscribers.

FIG. 3 shows an example of message flow in the architecture of FIG. 1,in the context of attempting a transaction.

FIG. 4 shows an example of message flow following FIG. 3 once thetransaction has been approved or denied, including an example flow of amessage sent to a transaction management entity for further processing.

FIG. 5 shows an example of message flow during a forensic investigationof a transaction of interest.

FIGS. 6-8 are block diagrams and flow diagrams illustrating the examplecreation of an association between logical identifiers assigned to enduser equipment and respective service point locations for that end userequipment, such association being useful in the population of thedatabase of FIG. 2A.

It is to be expressly understood that the description and drawings areonly for the purpose of illustration of certain embodiments of theinvention and are an aid for understanding. They are not intended to bea definition of the limits of the invention.

DETAILED DESCRIPTION OF NON-LIMITING EMBODIMENTS

FIG. 1 depicts a packet-switched network 14 to which are connected aplurality of merchant sites implemented by a plurality of servers 30 ₁ .. . 30 _(N). Computing devices that gain access to the packet-switchednetwork 14 can interact with the merchant sites in order to effectonline transactions. In a non-limiting embodiment, the packet-switchednetwork 14 is the Internet and the merchant sites are web sites.

Access to the packet-switched network 14 is controlled or managed by aservice provider that has a number of subscribers. In variousnon-limiting embodiments, the service provider may be an Access ServiceProvider (ASP), a Regional Access Network Provider (RANP) or an InternetService Provider (ISP). Individual subscribers are given permission toaccess the packet-switched network 14 when using certain authorized enduser equipment and/or when providing certain authorized logincredentials.

FIG. 1 shows one example of end user equipment 12 that may be used toaccess the packet-switched network 14 by a user 10. Specifically, theend user equipment 12 comprises a computing device 16 and a networkinterface unit 18. The computing device 16 may be implemented as apersonal computer (PC), such as a desktop computer, a laptop computer ora tablet PC. The computing device 16 is provided with at least one inputdevice such as a keyboard, a mouse, a touchscreen, a stylus, amicrophone, etc., as well as a display and possibly one or more otheroutput devices (e.g., speakers) that enable interaction with the user10. The computing device 16 is operative to run a software applicationimplementing a network browser (e.g., a web browser) with which the user10 can interact via the display (and possibly the one or more otheroutput devices) and the at least one input device in order to access andinteract with merchant sites of the packet-switched network 14.

A communication link 20 is provided between the end user equipment 12and the packet-switched network 14. The network interface unit 18interfaces with the communication link 20 and enables the computingdevice 16 to exchange data with the packet-switched network 14 (and,ultimately, with the merchant sites). For example, depending on thenature of the communication link 20, the network interface unit 18 maybe implemented as a modem such as a broadband modem (e.g., a digitalsubscriber line (DSL) modem or a cable modem) or a narrowband modem(e.g., a dial-up modem). In other embodiments, such as in the case ofFiber to the premises (FTTP), the network interface 18 may beimplemented as an optical network termination (ONT)-based Ethernetconnection. Although it is shown as being a separate component in FIG.1, the network interface unit 18 may be integrated into the computingdevice 16 (e.g., it may be a card internal to the computing device 16).

The communication link 20 may traverse one or more network elements andcomprise one or more physical links and one or more logical links. Forexample, the communication link 20 may comprise a physical link 17between the network interface unit 18 and a network element 21. Thephysical link 17 may comprise a copper twisted pair, a coax cable, anEthernet link, a fiber optic link (e.g., fiber to the premises (FTTP)),a fixed wireless link, a satellite link, or a combination thereof.Depending on the nature of the physical link 17, the network element 21may be a DSL access multiplexer (DSLAM), a cable modem terminationsystem (CMTS), or another type of network element. The communicationlink 20 may also comprise a dedicated logical link 19 between thenetwork element 21 and another network element 23 that provides accessto the packet-switched network 14. For instance, the network element 23may be a network access server (NAS), a router, etc. It will beappreciated that the communication link 20 may take on other forms inother embodiments.

For the purposes of exchanging data with the packet-switched network 14,the end user equipment 12 may be assigned a logical identifier. In twonon-limiting example embodiments, the logical identifier may be assignedto the computing device 16 or to the network interface unit 18. Thelogical identifier, which can be an Internet Protocol (IP) address(e.g., in compliance with IPv4 or IPv6) or a proprietary address, labelor tag, can be assigned in a static or dynamic fashion. In the staticcase (e.g., a static IP address), the logical identifier does not changeover time. In the dynamic case (e.g., a dynamic IP address), the logicalidentifier may change over time (e.g., a dynamic IP address).

Assignment of the logical identifier to the end user equipment 12 can beeffected under control of the service provider and may be theresponsibility of a designated network element that is part of thecommunication link 20, such as the network element 23 (particularly inembodiments where the network element 23 is a network access server).The designated network element may assign the logical identifier to theend user equipment 12 when the end user equipment 12 is activated (e.g.,when the network interface unit 18 and/or the computing device 16 is/arepowered-up) or otherwise regains network connectivity and/or at certaintime intervals which may range from an hour or less to several months ormore. For instance, in embodiments where the logical identifier is adynamic IP address, the network element assigning the dynamic IP addressto the end user equipment 12 may do so in accordance with the DynamicHost Configuration Protocol (DHCP) using a pool of IP addressesaccessible to that network element. It will be recognized thatassignment of the logical identifier to the end user equipment 12 may beeffected in different ways in different embodiments.

The service provider maintains a database 36 that stores informationassociated with the various logical identifiers assigned to various enduser equipment used to access the packet-switched network 14. Thedatabase 36 can be linked to various components of the infrastructure ofFIG. 6 in different ways. For example, in one embodiment, the database36 may be integrated with the network element 23. In another embodiment,the database 36 may be connected to the network element 23 eitherdirectly or via a service provider network 86, for example. In stillother embodiments, the database 36 may be distributed amongst aplurality of network elements and/or physical locations. Also, it shouldbe appreciated that the database 36 may be managed, maintained and/orupdated by an entity that may be the same entity as, or a differententity from, the service provider responsible for providing the end userequipment 12 with access to the packet-switched network 14.

With additional reference to FIG. 2A, there is shown an example ofpossible contents of the database 36. An example process by which thedatabase 36 may be populated and maintained is described later on. Forthe time being, it is sufficient to consider that the database 36 storesa plurality of records 40 ₁ . . . 40 _(M) for respective logicalidentifiers assigned to various end user equipment being used to accessthe packet-switched data network 14. The record for a particular logicalidentifier contains “evidentiary information” pertaining to the end userequipment to which the particular logical identifier was assigned.

Evidentiary information can be viewed as information that can serve asevidence towards establishing who has attempted/effected an onlinetransaction and/or where that online transaction was attempted/effectedfrom. The value of evidentiary information can be high wheninvestigating online transactions, particularly days or weeks after theyhave taken place. Such analysis may be commissioned by, inter alia,financial institutions (such as banks, credit card companies, etc.), aswell as government bodies (such as law enforcement agencies, taxationdepartments, etc.).

The evidentiary information that can be contained in a given one of therecords 40 ₁ . . . 40 _(M) is not particularly limited and may take onvarious forms, some of which are best illustrated by way of example.

Accordingly, a first example of evidentiary information that can becontained in the record for a given logical identifier includesinformation (such as name, age, gender, etc.) regarding a particularsubscriber whose credentials were supplied via the end user equipment towhich the given logical identifier was assigned, when access to thepacket-switched network 14 was sought.

A second example of evidentiary information that can be contained in therecord for a given logical identifier includes location informationindicative of where the end user equipment to which the given logicalidentifier was assigned was located, when access to the packet-switchednetwork 14 was sought. Such location information may specify a “servicepoint” at which the end user equipment was determined to be located. The“service point” refers to a point where a network access service isprovided to a subscriber by the service provider. By way of a specificnon-limiting example, the service point may be a house or otherbuilding, or an area thereof. The location of the service point, whichis hereinafter referred to as the “service point location”, may beexpressed as a geo location (latitude, longitude, elevation, and thedatum which identifies the coordinate system used, such as, withoutlimitation, the World Geodetic System 1984 (WGS841) datum).Alternatively or in addition, the service point location may beexpressed as a civic location (a set of elements that describe detailedstreet address information). Still other possibilities exist and arewithin the scope of the invention.

Returning to FIG. 1, the servers 30 ₁ . . . 30 _(N) and the merchantsites that they implement are operated, managed or otherwise associatedwith various entities, including, for example, companies, governmentalorganizations, non-profit organizations, and individuals. Each of theservers 30 ₁ . . . 30 _(N) comprises suitable hardware, firmware,software, control logic, or a combination thereof for implementing aplurality of functional components, including an interface and aprocessing unit.

The interface of each of the servers 30 ₁ . . . 30 _(N) is adapted toreceive messages from, and send messages to, communication equipment(such as the end user equipment 12) connected to the packet-switchednetwork 14, as well as to receive data from, or send data to, otherelements (e.g., computers or databases) communicatively coupled to thatserver but not necessarily connected to the packet-switched network 14.

The processing unit of each of the servers 30 ₁ . . . 30 _(N) is adaptedto effect various processing operations to implement that server'sfunctionality. For example, when the user 10 uses the end user equipment12 to interact with a given merchant site implemented by a given one ofthe servers 30 ₁ . . . 30 _(N), this will typically involve the networkbrowser implemented by the computing device 16 interacting with thegiven one of the servers 30 ₁ . . . 30 _(N) in order to allow the user10 to view, hear or otherwise be exposed to content (e.g., web pages) ofthe given merchant site via the display and/or one or more other outputdevices of the computing device 16, and to input information (e.g., byentering text, selecting an option, etc.) and/or one or more commands(e.g., by clicking on a graphical button or a hyperlink) via the atleast one input device of the computing device 16.

In accordance with an embodiment of the present invention, each of theservers 30 ₁ . . . 30 _(N) includes or has access to a correspondingmemory 90. The memory 90 corresponding to a given one of the servers 30₁ . . . 30 _(N) stores an association between, on the one hand, logicalidentifiers used by various end user equipment to effect transactionswith the given one of the servers 30 ₁ . . . 30 _(N) and, on the otherhand, “transaction identifiers” for those transactions. The contents ofthe memory 90 corresponding to a given server are kept up to date as newtransactions are effected with the given server.

A “transaction identifier” for a particular transaction may be generatedby an entity involved in validating or otherwise processing theparticular transaction. One example of such an entity includes a paymentgateway 60.

The payment gateway 60 is a network element that is connected to afinancial network 68 and that is used by one or more of the servers 30 ₁. . . 30 _(N) to process online transactions attempted to be made viathe merchant sites implemented by those one or more servers. Thefinancial network 68 interconnects a plurality of servers or othercomputers associated with banks and/or other financial institutions.Examples of servers that could be interconnected via the financialnetwork 68 include a transaction validation server 51 that could beassociated with, for example, a card issuing bank and a server 70 thatcould be associated with, for example, an acquiring bank. It should beappreciated that in certain embodiments, the financial network 68 may bepart of the packet-switched network 14, may comprise individualpoint-to-point links or may be dispensed with altogether.

The transaction validation server 51 may be connected to the variousservers 30 ₁ . . . 30 _(N) (or computers associated with those servers)via respective communication paths established over the packet-switchednetwork 14 and the financial network 68 and which may traverse one ormore network elements such as gateways and other servers. Thetransaction validation server 51 is operated, managed or otherwiseassociated with an entity responsible for validating onlinetransactions. In a specific non-limiting embodiment, this entity may bea card issuing bank that issues credit cards or debit cards.

The transaction validation server 51 comprises suitable hardware,firmware, software, control logic, or a combination thereof forimplementing a plurality of functional components, including aninterface and a processing unit. The interface of the transactionvalidation server 51 is adapted to receive messages from and sendmessages to other servers and/or other computers, and to exchange datawith other elements (e.g., databases). The processing unit of thetransaction validation server 51 is adapted to effect various processingoperations to implement that server's functionality.

The transaction validation server 51 includes or has access to adatabase 53, which stores information used by the transaction validationserver 51 to validate online transactions attempted to be effected byvarious users. Accordingly, the database 53 stores a plurality ofrecords, each of which is associated with a respective “transactionobject” and contains “transaction object information” pertaining to therespective transaction object, as well as ancillary information that maybe required to process an online transaction attempted to be made usingthe respective transaction object.

A “transaction object” refers to any physical or virtual object designedto be used in an attempt to make a transaction. For example, atransaction object may constitute a payment card (e.g., a credit card, adebit card, etc.), an account (e.g., a bank account, an online walletaccount, login credentials for accessing secure content or a VPN, etc.),an electronic check, a set of one or more digital cash (electronicmoney) certificates, or any other physical or virtual object designed tobe used in an attempt to make a transaction. The transaction objectinformation can therefore take on various forms.

For example, the transaction object information may include payment cardinformation regarding a payment card in situations where, for instance,the user 10 desires to purchase or otherwise obtain aproduct/service/content offered on a network site, pay a bill for apreviously obtained product/service/content via the network site, ormake a donation to a charity or other institution through the networksite using the payment card. Such payment card information may be, forinstance, credit card information regarding a credit card (e.g., anumber, expiry date, and/or holder's name) or debit card informationregarding a debit card (e.g., a number and/or holder's name). Thepayment card may comprise one or more card elements adapted to conveypart or all of the payment card information, such as one or more sets ofcharacters (e.g., printed and/or embossed characters), a magneticstripe, and/or a chip (e.g., an EMV chip).

In another example, the transaction object information may includeelectronic check information regarding an electronic check (e.g., acheck number and/or a checking account number) in situations where, forinstance, the user 10 desires to effect a payment via a network siteusing the electronic check. In order to process the payment attempted tobe effected by the user 10 using the electronic check, an entity (e.g.,a bank or other financial institution, or the service provider) thatallows the user 10 to use the electronic check may store on acomputer-readable medium (e.g., as part of a database) informationregarding the electronic check, including the electronic checkinformation provided by the user 10.

In yet another example, the transaction object information may includedigital cash information regarding a set of one or more digital cashcertificates (e.g., digital cash certificate identifiers) in situationswhere, for instance, the user 10 desires to effect a payment via anetwork site using the set of one or more digital cash certificates. Inorder to process the payment attempted to be effected by the user 10using the set of one or more digital cash certificates, an entity (e.g.,a bank or other financial institution) that allows the user 10 to usethe set of one or more digital cash certificates may store on acomputer-readable medium (e.g., as part of a database) informationregarding the set of one or more digital cash certificates, includingthe digital cash information provided by the user 10.

In a further example, the transaction object information may includeaccount information regarding an account (e.g., an account number and/orholder's name and/or login credentials) in situations where, forinstance, the user 10 desires to effect a transfer of funds to or fromthe account via a network site, or where the user 10 desires to accesssecure online content or a VPN via the network site. In order to processthe attempted transfer or access, an entity (e.g., a bank or otherfinancial institution, a corporate extranet server) that allows the user10 to use the account may store on a computer-readable medium (e.g., aspart of a database) information regarding the account, including theaccount information provided by the user 10.

The ancillary information contained in a particular record of thedatabase 53 also depends on the nature of the transaction objectassociated with the particular record and can thus take on many forms.For example, where the transaction object associated with the particularrecord is a credit card, the ancillary information contained in theparticular record may include a credit limit, a balance due, a billingaddress (i.e., an address where credit card bills are to be sent), ashipping address, a list of recent transactions, a list of one or moreauthorized transaction points (which could include the billing addressand/or the shipping address), a list of one or more unauthorizedtransaction points, a spatio-temporal history of previous onlinetransactions attempted using that credit card, a list of eligible cardholders' names and/or possibly other information regarding the creditcard.

In accordance with an embodiment of the present invention, the serviceprovider maintains a transaction management entity 80 including orhaving access to a transaction record database 82. The transactionmanagement entity 80 provides entities such as merchant sites, banks andcredit card companies with a centralized point to which informationregarding effected transactions can be sent. To this end, thetransaction management entity 82 may be reachable via thepacket-switched network 14 and the service provider network 86, or via adirect connection to one or more of the above entities. The contents ofthe transaction record database 82 are thus continuously updated basedon information about transactions taking place in the packet-switchednetwork 14, as received from a variety of sources.

With additional reference to FIG. 2B, there is shown an example ofpossible contents of the transaction record database 82. The transactionrecord database 82 stores a plurality of records 84 ₁ . . . 84 _(T) forvarious transactions that have been attempted/effected by varioussubscribers. The manner in which the transaction record database 82 ispopulated will be described later on in greater detail. Generallyspeaking, it can be said that a new record in the transaction recorddatabase 82 is created upon receipt of a transaction identifier and alogical identifier from an entity (such as a merchant site, bank orcredit card company) having recorded an attempt to effect a transaction.The transaction identifier can be used to index the new record, whilethe logical identifier can be used to look up one or more elements ofevidentiary information by consulting the database 36. The one or moreelements of evidentiary information returned from the database 36 arestored in the record that has just been created in the transactionrecord database 82 for the transaction in question.

To illustrate more specifically how the transaction record database 82may be populated, consider the situation where the user 10 decides toeffect an online transaction with the merchant site implemented by theserver 30 _(n). For example, the user 10 may decide to: purchase orotherwise obtain a product and/or a service and/or content offered onthe merchant site; pay a bill for a previously obtainedproduct/service/content via the merchant site; transfer funds from oneaccount to another via the merchant site; buy or sell securities (e.g.,stocks, bonds, etc.) via the merchant site; make a donation to a charityor other institution through the merchant site; etc. It will beappreciated that various other situations may arise in which onlinetransactions may be desired or may need to be effected.

For the purposes of the present example, it is assumed that the user 10has used the end user equipment 12 to successfully gain access to thepacket-switched network 14, and that the end user equipment 12 has beenassigned a logical identifier, say 211.104.103.102. Successful access tothe packet-switched network 14 may have been gained by the user 10having provided the credentials of a legitimate subscriber, say,subscriber “ABC”, via the end user equipment 12. Thus, with reference toFIG. 2A, the database 36 stores a record 40 _(X) for logical identifier211.104.103.102, which contains evidentiary information, such as theidentity of subscriber “ABC” (or other personal information pertainingto subscriber “ABC”). Alternatively or in addition, the service providerdetermines a service point location (say, “15 Main Street”) associatedwith the end user equipment 12 and stores this information in the record40 _(X). One way in which the service point location associated with theend user equipment 12 can be determined is described in greater detaillater on.

In the course of attempting to effect an online transaction whileinteracting with the merchant site implemented by the server 30 _(n),the user 10 provides transaction object information via the end userequipment 12. This can be done in various ways. For example, the user 10may use one or more of the at least one input device of the computingdevice 16 to enter the transaction object information and cause thisinformation to be sent by the end user equipment 12 to the server 30_(n) (or another computer associated with the server 30 _(n)) over thepacket-switched network 14. Alternatively, the transaction objectinformation may have been previously stored in the computing device 16,in which case the user 10 may use one or more of the at least one inputdevice of the computing device 16 to cause the end user equipment 12 tosend the previously stored transaction object information to the server30 _(n) (or another computer associated with the server 30 _(n)) overthe packet-switched network 14.

For purposes of this example, the transaction object is a particularcredit card, the transaction object information is credit cardinformation regarding the particular credit card and the transactionvalidation server 51 is a server associated with a card issuing bankthat issued the particular credit card. Also, for purposes of thisexample, each of the records in the database 53 is associated with acredit card and includes credit card information regarding that creditcard. One of these records may be associated with the particular creditcard and thus may include credit card information regarding theparticular credit card.

The online transaction attempted to be effected by the user 10 may besubjected to various conventional security measures intended to protectinformation traveling to and from the end user equipment 12 over thepacket-switched network 14. For example, the credit card informationprovided by the user 10 via the end user equipment 12 may be encrypted(e.g., using the Secure Socket Layer (SSL) protocol) prior to being sentover the packet-switched network 14. In other examples, card securitycode (CSC) verification may be employed whereby the user 10 is asked toenter the credit card's CSC, and/or address verification systems (AVS)may be employed whereby an address entered by the user 10 is compared toa billing address known to the credit card's issuing bank. Various othersecurity measures may be employed in different cases.

With reference now to FIG. 3, the computing device 16 of the end userequipment 12 transmits to the server 30 _(n) a message 102. In thisexample, the message 102 conveys: (i) order information indicative ofthe selected product/service/content; (ii) purchase amount informationindicative of an amount to be paid to purchase the selectedproduct/service/content; and (iii) the credit card information regardingthe particular credit card. Alternatively, the order information, thepurchase amount information and possibly even the credit cardinformation may already be known to the server 30 _(n) due to priorinteraction between the computing device 16 and the server 30 _(n). Insuch a case, the message 102 may simply convey an indication orconfirmation of a desire of the user 10 to purchase the selectedproduct/service/content.

Additionally, the message 102 may also convey the logical identifierassigned to the end user equipment 12, in this case 211.104.103.102.Alternatively, the logical identifier assigned to the end user equipment12 may not be conveyed by the message 102 but may already be known tothe server 30 _(n) due to prior interaction between the computing device16 and the server 30 _(n).

The message 102 is received at the server 30 _(n), which proceeds tosend a message 104 to a payment gateway 60. In this example, the paymentgateway 60 is used by the server 30 _(n) to process online transactionsattempted to be made via the merchant site implemented by the server 30_(n). Thus, the manner in which the payment gateway 60 can be reachedmay be known in advance to the server 30 _(n). It is recalled that thefinancial network 68 interconnects the payment gateway 60 to thetransaction validation server 51 (which is associated with the cardissuing bank that issued the particular credit card) and the server 70(which is associated with the acquiring bank used by the merchant thatoperates, manages or is otherwise associated with the server 30 _(n)).

The message 104 sent to the payment gateway 60 may be identical to themessage 102, i.e., it may be a relayed version of the message 102 whenthe message 102 contains sufficient information. Alternatively, themessage 104 may be generated by the server 30 _(n) based on the message102 and possibly other information known to the server 30 _(n) (e.g.,the order information, the purchase amount information and/or the creditcard information). Ultimately, in this example, the message 104 conveys:(i) the purchase amount information indicative of an amount to be paidto purchase the selected product/service/content; and (ii) the creditcard information regarding the particular credit card.

The message 104 is received at the payment gateway 60 which, inaccordance with a specific non-limiting embodiment of the presentinvention, proceeds to generate a unique transaction identifier for theparticular transaction being attempted. By way of specific non-limitingexample, let the transaction identifier be A7GH6X. Also, havingdetermined that the message 104 originates from the server 30 _(n), thepayment gateway 60 proceeds to send a message 106 over the financialnetwork 68 to the server 70 (which, it is recalled, is associated withthe acquiring bank used by the merchant associated with the server 30_(n)). The message 106, which can be viewed as a request for transactionauthorization, is intended to elicit from the financial network 68 aresponse as to whether the transaction identified by the transactionidentifier A7GH6X is approved or denied. In this example, the paymentgateway 60 generates the message 106 based on the message 104 such thatthe message 106 conveys: (i) the purchase amount information indicativeof an amount to be paid to purchase the selectedproduct/service/content; and (ii) the credit card information regardingthe particular credit card. The transaction identifier A7GH6X may alsobe provided to facilitate processing.

The server 70 receives the message 106 and processes it to gainknowledge that an attempt is being made to effect a transaction havingthe transaction identifier A7GH6X and involving the merchant associatedwith the server 30 _(n). Based on the credit card information conveyedby the message 106, the server 70 proceeds to send a message 108 to thetransaction validation server 51 over the financial network 68. Themessage 108 may be identical to the message 106, i.e., it may be arelayed version of the message 106. Alternatively, the message 108 maybe generated by the server 70 based on the message 106 and possiblyother information known to the server 70. In this example, the message108 conveys: (i) the purchase amount information indicative of an amountto be paid to purchase the selected product/service/content; and (ii)the credit card information regarding the particular credit card. Thetransaction identifier A7GH6X may also be provided to facilitateprocessing.

The message 108 is received at the transaction validation server 51,which is associated with the card issuing bank that issued theparticular credit card that has been used by the user 10 to attempt topurchase the selected product/service/content. The transactionvalidation server 51 proceeds to process the message 108 to determinewhether the transaction identified by the transaction identifier A7GH6Xis to be approved or denied. To this end, the transaction validationserver 51 consults the database 53 to identify a particular one of therecords therein for the credit card information conveyed by the message108.

The transaction validation server 51 may perform various processingoperations to determine whether the transaction identified by thetransaction identifier A7GH6X is to be approved or denied. For example,based on the ancillary information (e.g., a credit limit, a balance due,etc.) included in the particular one of the records in the database 53and the purchase amount information conveyed by the message 108, thetransaction validation server 51 may determine whether the transactionidentified by the transaction identifier A7GH6X is to be approved ordenied. It will be appreciated that approval or denial of thetransaction identified by the transaction identifier A7GH6X may bedetermined by the transaction validation server 51 based on otherfactors in addition to or instead of those mentioned above.

With reference now to FIG. 4, upon determining whether the transactionidentified by the transaction identifier A7GH6X is approved or denied,the transaction validation server 51 returns a message 114 to the server70 over the financial network 68. The message 114 indicates whether thetransaction identified by the transaction identifier A7GH6X was approvedor denied.

If the transaction identified by the transaction identifier A7GH6X wasdenied, the message 114 may indicate (e.g., by a code) a reason for thisdenial, such as insufficient funds, an unavailable bank link, etc.Depending on the circumstances, the transaction validation server 51 mayalso take further action, such as freezing a credit accountcorresponding to the particular credit card, informing security/lawenforcement authorities, etc.

On the other hand, if the transaction identified by the transactionidentifier A7GH6X was approved, the transaction validation server 51 mayupdate, in the database 53, the record associated with the particularcredit card to take into account approval of this transaction. Forexample, one or more elements of ancillary information (e.g., a balancedue, an available credit, etc.) included in the record in question maybe updated to reflect the fact that the transaction identified by thetransaction identifier A7GH6X was approved.

The server 70 receives the message 114, and processes it to determinewhether the transaction identified by the transaction identifier A7GH6Xwas approved or denied. If approved, the transaction identified by thetransaction identifier A7GH6X is eventually settled via a settlementprocess involving the acquiring bank and the card issuing bank. Thissettlement process is well known and thus not described herein.Meanwhile, the server 70 proceeds to return a message 116 to the paymentgateway 60. The message 116 may be identical to the message 114, i.e.,it may be a relayed version of the message 114. Alternatively, themessage 116 may be generated by the server 70 based on the message 114.The message 116 indicates whether the transaction identified by thetransaction identifier A7GH6X was approved or denied and, if denied, mayindicate a reason therefor.

The message 116 is received at the payment gateway 60, which proceeds tosend a message 118 to the server 30 _(n). The message 118 indicateswhether the transaction identified by the transaction identifier A7GH6Xwas approved or denied and, if denied, may indicate a reason therefor.The information conveyed by the message 118 issued by the paymentgateway includes the transaction identifier A7GH6X.

The server 30 _(n) receives the message 118, including the transactionidentifier A7GH6X. The server 30 _(n) processes the message 118 toascertain whether the transaction identified by the transactionidentifier A7GH6X was approved or denied. Approval or denial (and areason for denial, if applicable) may be recorded by the server 30 _(n),for future reference. The server 30 _(n) proceeds to send a message 120to the computing device 16 of the end user equipment 12 in order tocommunicate approval or denial of the online transaction to the user 10.

Upon receiving the message 120, the computing device 16 processes themessage 120 so as to communicate approval or denial of the onlinetransaction to the user 10. For example, this may be achieved bydisplaying a “transaction approved” or “transaction denied” message (orany conceivable variant thereof) on the display of the computing device16.

In addition, the server 30 _(n) stores the transaction identifierreceived with the message 118 (in this case A7GH6X) in association withthe logical identifier assigned to the end user equipment 12 used toeffect the transaction in question (in this case 211.104.103.102). Thiscan be done by creating a record in the memory 90. The storedassociation between the transaction identifier A7GH6X and the logicalidentifier 211.104.103.102 may prove valuable when it comes to launchinga possible investigation into potential fraudulence of illegality of thetransaction identified by the transaction identifier A7GH6X.

In addition, the server 30 _(n) generates a message 121 that is sent tothe transaction management entity 80. The message 121 can be sent to thetransaction management entity 80 over the packet-switched network 14 orover a dedicated link, for example. The message 121 contains theaforementioned information that was stored in the memory 90 of theserver 30 _(n), namely (i) the transaction identifier A7GH6X for thetransaction in question and (ii) the logical identifier 211.104.103.102assigned to the end user equipment 12 that was used to effect thetransaction in question. As an option, once the message 121 is sent tothe transaction management entity 80, the association between thetransaction identifier A7GH6X and the logical identifier 211.104.103.102need no longer be maintained in the memory 90 of the server 30 _(n).

The transaction management entity 80 is attentive to receipt of themessage 121, upon receipt of which the transaction management entity 80extracts therefrom the transaction identifier A7GH6X and the logicalidentifier 211.104.103.102. The transaction management entity 80 thenqueries the database 36 on the basis of the received logical identifier211.104.103.102 to obtain evidentiary information contained in therecord associated with the logical identifier 211.104.103.102.

It is recalled that the evidentiary information may take on variousforms, such as a subscriber identity or other personal informationand/or a service point location, to name a few non-limitingpossibilities. In the non-limiting example being considered here, record40 _(X) in the database 36, which is associated with the logicalidentifier 211.104.103.102, stores the identity of subscriber “ABC” andthe service point location “15 Main Street”. The transaction managemententity 80 then creates a new record 84 _(j) in the transaction recorddatabase 82, which relates the transaction identifier A7GH6X receivedfrom the server 30 _(n) to the evidentiary information (the identity ofsubscriber “ABC” and the service point location “15 Main Street”)received from the database 36.

The records 84 ₁ . . . 84 _(T) in the transaction record database 82(including the record 84 _(j)) thus relate timely obtained evidentiaryinformation to transaction identifiers. The evidentiary information canthen be provided at some later time to an interested party in responseto an eventual request from the latter specifying a particular one ofthese transaction identifiers.

Several applications of the transaction record database 82 are nowdescribed. Firstly, consider the scenario where, at the time when atransaction (such as the aforesaid transaction identified by thetransaction identifier A7GH6X) is effected, the service provider doesnot necessarily have an indication of whether this transaction isfraudulent or illegal. However, at some later time, let it be assumedthat an interested party adopts a more suspicious view, based on its ownresearch, customer complaints, a fraud detection mechanism, etc. Theinterested party may then undertake a forensic investigation regarding a“transaction of interest” associated with a particular transactionidentifier.

With reference now to FIG. 5, the investigation proceeds with aninterested party 500 (such as a merchant, a bank, a credit card company,a law enforcement agency, a governmental body, etc.) identifying theparticular transaction identifier associated with the transaction ofinterest. To this end, the interested party 500 may send a message 502to the transaction management entity 80 specifying the particulartransaction identifier. The message 502 may reach the transactionmanagement entity 80 via the packet-switched network 14 and the serviceprovider network 86. Alternatively, the message 502 may reach thetransaction management entity 80 via a direct link from the interestedparty 500. The transaction management entity 80 consults the transactionrecord database 82 in an attempt to match the particular transactionidentifier with the transaction identifier stored in one of the records84 ₁ . . . 84 _(T). If a match is not found, then the service providerhas not stored a record of this transaction having taken place, and theinterested party may wish to query other service providers who may haveprovided a conduit for the transaction of interest.

Assuming however that a matching record is identified, the correspondingevidentiary information (or a portion thereof) is retrieved from thetransaction record database 82 and provided to the interested party inthe form of a message 504. The level of detail provided in the message504 could vary depending on the relationship between the interestedparty and the service provider. Thus, it is within the scope of thepresent invention to allow a law enforcement agency to be privy to agreater amount of detail concerning the evidentiary information than acredit card company.

In one embodiment, where the transaction of interest is known to befraudulent (e.g., a fraudulent purchase, login, etc.), the evidentiaryinformation may reveal to the interested party certain details about theculprit. For example, when the evidentiary information provided in themessage 504 comprises a service point location, then the interestedparty may conclude where the fraudulent transaction of interest was madefrom. In another example, when the evidentiary information provided inthe message 504 comprises the identity of a particular subscriber, thenthe interested party may conclude who is guilty of having effected thetransaction of interest. Other example scenarios are of course possible,and each may lead to specific actions that may be taken by theinterested party to identify and then pursue and/or prosecute theculprit, as will be appreciated by those skilled in the art.

In another embodiment, the evidentiary information may reveal to theinterested party that the transaction of interest has a likelihood ofhaving been illegal or fraudulent. For example, when the evidentiaryinformation provided in the message 504 comprises a service pointlocation, and if the particular credit card is authorized to be at anyof a limited set of locations which do not include the service pointlocation provided in the message 504, the interested party may concludethat the transaction of interest was fraudulent. In another example,when the evidentiary information provided in the message 504 comprisesthe identity of a particular subscriber, and if the particularsubscriber is found to be or is registered as being of a certain age,the interested party may conclude that the transaction of interest wasillegal. Other example scenarios are of course possible, and each maylead to specific actions that may be taken by the interested party tofurther investigate the issue of fraud, as will be appreciated by thoseskilled in the art.

In a second scenario for using the transaction record database 82,rather than contain the particular transaction identifier, the message502 may contain target evidentiary information, such as a specific useror a specific location. Upon receipt of the message 502, the transactionmanagement entity 80 consults the transaction record database 82 in anattempt to match the target evidentiary information with the evidentiaryinformation stored in one or more of the records 84 ₁ . . . 84 _(T).Assuming that a matching record is identified, the correspondingtransaction identifier(s) is(are) retrieved from the transaction recorddatabase 82 and provided to the interested party in the form of themessage 504. In the case where a particular suspect has been identified,for example, this application of an embodiment of the present inventionallows the interested party to access transaction identifiers pertainingto all the transactions having been effected by that suspect (or from aspecific location associated with that suspect). These transactionidentifiers can be related to the actual transactions and analyzed forfraudulent activity in order to help establish the innocence or guilt ofthe suspect.

In a third scenario for using the transaction record database 82,consider the case where an interested party wishes to be notified whenonline transactions are attempted by a specific user or from a specificlocation (e.g., from a prison with Internet access). In one embodiment,in a provisioning phase, the transaction management entity 80 receives arequest containing “evidentiary information of interest”. Then, at thetime when a transaction (such as the aforesaid transaction identified bythe transaction identifier A7GH6X) is effected, the transactionmanagement entity 80 checks the evidentiary information against thetarget evidentiary information and, if there is a match, the interestedparty can be alerted by sending the corresponding transactionidentifier. The interested party then relates the transaction identifierto the transaction and establishes legitimacy/legality of thetransaction.

In the scenarios considered above, the transaction identifier A7GH6X wasgenerated by the payment gateway 60 upon receipt of the message 104, andwas relayed to the server 30 _(n) as part of the message 118. However,it should be appreciated that in various alternative embodiments, thetransaction identifier A7GH6X may have been generated by the paymentgateway 60 later on in the transaction validation, such as upon receiptof the message 116 from the server 70. Also, the transaction identifierA7GH6X could have been generated by other network entities involved inprocessing of the transaction and at various instances, such as:

-   -   by the server 70 upon receipt of message 106 from the payment        gateway 60;    -   by the transaction validation server 51 upon receipt of the        message 108 from the server 70;    -   by the server 70 upon receipt of the message 114 from the        transaction validation server 51;    -   by the server 30 _(n) upon originally receiving the message 102        from the computing device 16; or    -   by a shipping agent that produces a waybill.

Still other possibilities are within the scope of the present invention.

It should also be appreciated that although the payment gateway 60, theserver 70, the transaction validation server 51 and the server 30 _(n)have been described as separate entities, this has been done forconvenience and illustration only. It should therefore be understoodthat in certain embodiments, any one or more of the payment gateway 60,the server 70, the transaction validation server 51 and the server 30_(n) may be integrated into a single network entity or component.

In the scenarios considered above, the relationship between thetransaction identifier A7GH6X and the logical identifier 211.104.103.102was maintained by the server 30 _(n) in its memory 90 and then was sentto the transaction management entity 80. However, it should beappreciated that in various alternative embodiments, this relationshipmay be maintained by other entities of interest prior to being sent tothe transaction management entity 80, such as:

-   -   by the payment gateway 60 (in which case the message 104 sent        from the server 30 _(n) to the payment gateway 60 can be        modified to inform the payment gateway of the logical identifier        211.104.103.102);    -   by the server 70 (in which case both the message 104, as well as        the message 106 sent from the payment gateway 60 to the server        70, can be modified to inform the server 70 of the logical        identifier 211.104.103.102); or    -   by the transaction server 51 (in which case the messages 104 and        106, as well as the message 108, can be modified to inform the        transaction server of the logical identifier 211.104.103.102).

Still other possibilities are within the scope of the present invention.

In the scenarios considered above, the transaction identifier A7GH6X andthe logical identifier 211.104.103.102 were sent to the transactionmanagement entity 80, which then obtained evidentiary information fromthe database 36 based on the received logical identifier211.104.103.102. The resultant relationship between the transactionidentifier A7GH6X and the retrieved evidentiary information was thenstored in the record 84 _(j) of the transaction record database 82.However, it should be appreciated that in various alternativeembodiments, this relationship may be maintained by other entities ofinterest, such as by a third party (e.g., a law enforcement agency'sInternet server) reachable via the packet-switched network 14. Forexample, the transaction management entity 80 may transmit the retrievedevidentiary information along with the corresponding transactionidentifier A7GH6X to the law enforcement agency's Internet server forstorage thereon.

As has been mentioned above, the evidentiary information that can becontained in the record for a given logical identifier may includelocation information indicative of where the end user equipment to whichthe given logical identifier was assigned was located when access to thepacket-switched network 14 was sought. An example process by which thedatabase 36 may be populated with such location information will now bedescribed with reference to FIG. 6. Specifically, this exampledescription will illustrate one possible manner by which an associationbetween the logical identifier assigned to the end user equipment 12 andthe location of a service point where the end user equipment 12 islocated (e.g., “15 Main Street”), may be stored in the database 36 aspart of one of the records 40 ₁ . . . 40 _(M).

In this example, the network element 21 of the communication link 20connecting the end user equipment 12 to the packet-switched network 14is an access multiplexer. In one embodiment, the access multiplexer 21may be a DSLAM. The access multiplexer 21 is connected to the networkelement 23, which, in this embodiment, is a network access server (NAS).The NAS 23, which may also sometimes be referred to as a broadbandremote access server (BRAS), a remote access server (RAS) or a broadbandaccess server (BAS), provides access to the packet-switched network 14.Communication between the access multiplexer 21 and the NAS 23 can takeplace over the dedicated logical link 19 between these elements. Thededicated logical link 19, which may traverse an intervening access datanetwork (not shown), can be implemented in various ways. For example, inone embodiment, the dedicated logical link 19 may be implemented as anasynchronous transfer mode (ATM) permanent virtual circuit (PVC). Inanother embodiment, the dedicated logical link 19 may be implemented asa virtual local area network (VLAN). It will be appreciated that variousother implementations of the dedicated logical link 19 are possible.

The access multiplexer 21 allows data arriving from the NAS 23 alonggiven ATM PVCs, VLANs or other dedicated logical links to be sent overcorresponding physical links via corresponding one of its ports, andvice versa. Thus, the access multiplexer 21 can be said to implement amapping 134 between, on the one hand, dedicated logical links and, onthe other, ports of the access multiplexer 21. In this example, themapping 134 implemented by the access multiplexer 21 relates thededicated logical link 19 to the port 104 of the access multiplexer 21.In one example embodiment, the mapping 134 can be maintained by theaccess multiplexer 21.

In another example embodiment, the mapping 134 can be maintained by anoperation support system (OSS) 122. The OSS 122 represents a collectionof systems that perform management, inventory, engineering, planning,repair and other functions for a service provider. The OSS 122 may beconnected to the NAS 23 via the service provider network 86. One of thefunctions of the OSS 122 may include management of network elements,assets and equipment. Thus, the OSS 122 maintains a mapping 124 between,on the one hand, ports of various access multiplexers or other networkelements under control of the service provider and, on the other,service point locations of end user equipment (such as the end userequipment 12) connected to those ports. In this case, the mapping 124maintained by the OSS 122 relates a port 104 of the network element 21to a service point location, i.e., the location of a service point wherethe end user equipment 12 is located. As mentioned previously, thisservice point location may be expressed as a civic address, a geolocation, or any other information identifying where the service pointis located. In this specific example, it is assumed that the servicepoint location is “15 Main Street”.

The infrastructure shown in FIG. 6 further comprises an authorizationelement 142, which can be connected to the NAS 23 via the serviceprovider network 86. The nature of the connection between the NAS 23 andthe authorization element 142 is immaterial. For example, in oneembodiment, the authorization element 142 may be a server (e.g., anAuthentication, Authorization, and Accounting (AAA) server) responsiveto queries from the NAS 23. In such an embodiment, the authorizationelement 142 and the NAS 23 may communicate using the RemoteAuthentication Dial In User Service (RADIUS) protocol, a description ofwhich is available at www.ietf.org/rfc/rfc2865.txt. In anotherembodiment, the authorization element 142 may be a functional elementintegrated with the NAS 23.

In this example, the NAS 23 is operative to maintain a pool 127 ofpre-allocated logical identifiers that can be used by various end userequipment, including the end user equipment 12. In some embodiments, thepool 127 of logical identifiers may be built up as a cooperative effortbetween the NAS 23 and the OSS 122, while in other embodiments, it maynot be necessary for the OSS 122 to be involved in creating the pool 127of logical identifiers. In still other embodiments, the pool 127 oflogical identifiers may be maintained by the authorization element 142,and may be made accessible to the authorization element 142 withoutneeding to pass through the NAS 23.

It will be appreciated that numerous modifications and variations of theinfrastructure of FIG. 6 are possible. For example, in some embodiments,the access multiplexer 21 can be omitted. This may be true inembodiments where the end user equipment 12 implements a wireless accesspoint. For instance, in such embodiments, the connection between thewireless access point and the NAS 23 may be provided by a dedicatedpoint-to-point link. As another example, in some embodiments, instead ofthe dedicated logical link 19, there may be a shared link leading to theend user equipment 12.

Reference is now made to FIG. 7, which illustrates an example of apossible event flow upon activation of the end user equipment 12, whichmay occur, for instance, as the network interface unit 18 and/or thecomputing device 16 of the end user equipment 12 is/are powered up.Thereafter:

-   -   a) the end user equipment 12 establishes physical layer        connectivity with the access multiplexer 21 over the physical        link 17;    -   b) this is followed by establishment of Ethernet connectivity        between the end user equipment 12 and the access multiplexer 21;    -   c) the end user equipment 12 verifies its ability to communicate        using Point-to-Point Protocol over Ethernet (PPPoE). For a more        detailed explanation of PPPoE, one may refer to Internet Request        For Comments (RFC) 2516, available from the Internet Engineering        Task Force (http://www.ietf.org), hereby incorporated by        reference herein;    -   d) next, assuming that the end user equipment 12 has the ability        to communicate using PPPoE, the end user equipment 12 verifies        whether it should make a so-called “access request”        automatically or in response to user input (which can be        obtained via a software application). For purposes of this        example, let it be assumed that conditions have been met such        that the end user equipment 12 should make an access request;    -   e) the end user equipment 12 begins entry into PPPoE        communication by broadcasting an “initiation” packet over the        dedicated logical link 19;    -   f) the NAS 23 responds to receipt of the initiation packet by        sending an “offer” packet to the end user equipment 12. At this        stage, it can be said that a logical connection 182 has been        defined between a first endpoint (the end user equipment 12) and        a second endpoint (the NAS 23);    -   g) following receipt of the offer packet, the end user equipment        12 sends an access request 184 to the NAS 23 with the ultimate        goal of accessing the packet-switched network 14. The access        request 184 may comprise credentials that can be hard coded or        programmably installed on the end user equipment 12.        Alternatively, the credentials may be entered by the user 10 of        the end user equipment 12.    -   h) upon receipt of the access request 184 containing the        credentials along the dedicated logical link 19, the NAS 23        executes an authorization procedure as follows. The NAS 23        communicates the credentials to the authorization element 142,        e.g., via a RADIUS Access-Request message 188. In response to        receipt of the credentials from the NAS 23, the authorization        element 142 determines whether the credentials allow access to        the packet-switched network 14. For example, this can be        determined by consulting a database (not shown) of credentials        for various subscribers. If the credentials allow access to the        packet-switched network 14, the authorization element 142        returns an acceptance message (e.g., a RADIUS Access-Accept        message). On the other hand, if the credentials do not allow        access to the packet-switched network 14, the authorization        element 142 returns a refusal message (e.g., a RADIUS        Access-Reject message). For purposes of this example, assume        that the credentials allow access to the packet-switched network        14, resulting in issuance of an acceptance message 190. In this        example, two alternatives are possible        -   alternative 1 (where the pool 127 of logical identifiers is            maintained by the authorization element 142): the            authorization element 142 obtains a logical identifier 193            from the pool 127 of logical identifiers that is maintained            by the authorization element 142. The logical identifier 193            is sent to the NAS 23, which assigns the logical identifier            193 to the dedicated logical link 19;        -   alternative 2 (where the pool 127 of logical identifiers is            maintained by the NAS 23): responsive to receipt of the            acceptance message 190 from the authorization element 142,            the NAS 23 obtains a logical identifier 193 from the pool            127 of logical identifiers that is maintained by the NAS 23.            The logical identifier 193 so obtained is assigned by the            NAS 23 to the dedicated logical link 19.    -   i) the NAS 23 sends a “confirmation” packet back to the end user        equipment 12, thus completing establishment of a PPPoE session        between the endpoints of the logical connection 182;    -   j) additional hand-shaking may be performed between the end user        equipment 12 and the NAS 23 in order to establish a        Point-to-Point Protocol (PPP) session between the endpoints of        the logical connection 182;    -   k) following this, further hand-shaking may be undertaken        between the end user equipment 12 and the NAS 23 in order to        establish an Internet Protocol Control Protocol (IPCP) session        between the endpoints of the logical connection 182.    -   l) during the IPCP session, the NAS 23 releases the logical        identifier 193 towards the end user equipment 12 that issued the        access request 184, in order to allow the end user equipment 12        to identify itself using the logical identifier 193 in future        communications over the dedicated logical link 19. Since the        dedicated logical link 19 to which has been assigned the logical        identifier 193 leads to the end user equipment 12 and since the        end user equipment 12 will identify itself using the logical        identifier 193 in future communications, it can be said that the        logical identifier 193 is in actuality assigned to the end user        equipment 12.

It can thus be appreciated that once the logical identifier 193 has beenobtained from the pool 127 of logical identifiers (either by the NAS 23or by the authorization element 142), the NAS 23 assigns the logicalidentifier 193 to the dedicated logical link 19.

In an embodiment where the database 36 is integrated with or connecteddirectly to the NAS 23, the fact that the NAS 23 assigns the logicalidentifier 193 to the dedicated logical link 19 allows the NAS 23 toconstruct and maintain a mapping 144 between, on the one hand, variousdedicated logical links (such as the dedicated logical link 19 andothers) and, on the other, logical identifiers corresponding to thosededicated logical links.

In an embodiment where database 36 is integrated with or connecteddirectly to the authorization element 142, the logical identifier 193and the identity of the dedicated logical link 193 to which it isassigned are sent back by the NAS 23 to the authorization element 142,and it is the authorization element 142 that maintains theaforementioned mapping 144 between dedicated logical links and logicalidentifiers corresponding to those dedicated logical links.

Of course, those skilled in the art will be able to think of other waysof causing the end user equipment 12 to send the access request 184 overthe logical connection 182 between the end user equipment 12 and the NAS23, as well as other ways of assigning a logical identifier to thededicated logical link 19. It should further be mentioned that, in somecases, the establishment of the aforementioned PPPoE, PPP and/or IPCPsessions may not be required. This is particularly the case where thededicated logical link 19 is a VLAN.

In view of the preceding description, and in particular given thepreviously described mappings 124, 134 maintained in the OSS 122 and/orthe access multiplexer 21 and the previously described mapping 144maintained in the NAS 23 or the authorization element 142, the followingdescribes how one can create an association between logical identifiersand service point locations.

Specifically, with reference to FIG. 8, by combining the mapping 124with the mapping 134, the OSS 122 can create an intermediate mapping 166between, on the one hand, dedicated logical links and, on the otherhand, service point locations of end user equipment having logicalconnections with the NAS 23 which traverse those dedicated logicallinks. In this example, the intermediate mapping 166 would associate thededicated logical link 19 to the service point location of the end userequipment 12. In one embodiment, the OSS 122 transmits the intermediatemapping 166 to the database 36 (or a server associated therewith).

At the database 36 (or a server associated therewith), the intermediatemapping 166 received from the OSS 122 may be combined with theaforementioned mapping 144 (received from the NAS 23 or theauthorization element 142), thus creating a final mapping 176 between,on the one hand, logical identifiers (such as IP addresses) and, on theother, service point locations of end user equipment having logicalconnections with the NAS 23 which traverse respective dedicated logicallinks to which those logical identifiers have been assigned. In thisexample, the final mapping 176 would specify that the logical identifier193 corresponds to the service point location of the end user equipment12. This is precisely the type of association that is useful to store inthe database 36.

It will also be appreciated that in embodiments where logicalidentifiers are dynamically assigned to various end user equipment 12(e.g., in a dynamic IP address system), the database 36 may be updatedaccordingly.

From the above, it should be apparent that the database 36 can bepopulated with logical identifiers (such as IP addresses) and servicepoint locations associated with those logical identifiers. Moregenerally, the database 36 can be populated with records for variouslogical identifiers, each record containing location information. Thelocation information that can be contained in the record for a givenlogical identifier may be indicative of where the end user equipment towhich the given logical identifier was assigned was located when accessto the packet-switched network 14 was sought.

While the above-described example illustrates one possible technique forpopulating a portion of the database 36, it will be appreciated thatdifferent techniques may be employed in different embodiments.

Although the above-described example relates to an online transactioninvolving an online purchase using a credit card, it will be recognizedthat principles described herein apply to other types of onlinetransactions, including, for example, those involving online purchasesor payments using other payment objects (e.g., digital cash, electronicchecks), online fund transfers involving accounts (e.g., bank accounts,online wallet accounts), attempts to access secure online content; andattempts to access a virtual private network, to name a few non-limitingpossibilities.

It should further be appreciated that although the above references toonline transactions have involved the computing device 16 effecting anonline transaction with a merchant site over the packet-switched network14, it is also within the scope of the invention for the computingdevice 16 to be implemented as a communication device which is one partyto a call and which effects an online transaction with another partyreachable over the packet-switched network 14. Specifically, thecommunication device could be embodied as a VoIP phone, a Plain OldTelephone Service (POTS) phone equipped with an analog terminal adapter(ATA), or a soft phone (i.e., a computer equipped with telephonysoftware). For its part, one party to the call can be a purveyor ofgoods or services.

It should further be appreciated that any one or more of the abovedescribed messages 102, 104, 106, 108, 114, 116, 118, 120, 121 may beencrypted prior to being transmitted. This encryption may be effectedusing the SSL protocol or some other suitable encryption technique,without limitation.

Those skilled in the art will also appreciate that, in some embodiments,certain functionality of a given component described herein (e.g., thetransaction validation server 51, the server 70, the payment gateway 60,the transaction management server 80, the servers 30 ₁ . . . 30 _(N))may be implemented as pre-programmed hardware or firmware elements(e.g., application specific integrated circuits (ASICs), electricallyerasable programmable read-only memories (EEPROMs), etc.) or otherrelated elements. In other embodiments, the given component may comprisea processor having access to a code memory which stores programinstructions for operation of the processor to implement functionalityof that given component. The program instructions may be stored on amedium which is fixed, tangible, and readable directly by the givencomponent (e.g., removable diskette, CD-ROM, ROM, fixed disk, USB key,etc.). Alternatively, the program instructions may be stored remotelybut transmittable to the given component via a modem or other interfacedevice connected to a network over a transmission medium. Thetransmission medium may be either a tangible medium (e.g., optical oranalog communications lines) or a medium implemented using wirelesstechniques (e.g., RF, microwave, infrared or other wireless transmissionschemes).

Although various embodiments of the present invention have beendescribed and illustrated, it will be apparent to those skilled in theart that numerous modifications and variations can be made withoutdeparting from the scope of the invention, which is defined in theappended claims.

1. A method, comprising: receiving a first identifier associated with anonline transaction and a second identifier used by end user equipmentinvolved in the online transaction; obtaining evidentiary informationpertaining to the end user equipment based on the second identifier;storing in a database a record that associates the first identifier withthe evidentiary information; and retrieving one of (i) the evidentiaryinformation in said record and (ii) the first identifier in response toa request identifying the other of (i) the evidentiary information insaid record and (ii) the first identifier.
 2. The method defined inclaim 1, wherein the request identifies the first identifier.
 3. Themethod defined in claim 2, wherein the request is received after saidreceiving the first identifier.
 4. The method defined in claim 3,wherein the request is issued by a party conducting a forensicinvestigation of the online transaction.
 5. The method defined in claim1, wherein the request identifies the evidentiary information.
 6. Themethod defined in claim 5, wherein the request is received after saidreceiving the first identifier.
 7. The method defined in claim 5,wherein the request is received prior to said receiving the firstidentifier.
 8. The method defined in claim 7, wherein the request isissued by a party monitoring online transactions effected by a userassociated with the first identifier.
 9. The method defined in claim 1,wherein the second identifier is a logical identifier assigned to theend user equipment.
 10. The method defined in claim 9, wherein thesecond identifier is an Internet Protocol address.
 11. The methoddefined in claim 9, wherein the online transaction is effected over anetwork, the method further comprising assigning the logical identifierto the end user equipment in response to the end user equipmentrequesting access to the network.
 12. The method defined in claim 9,wherein obtaining the evidentiary information comprises consulting asecond database comprising a plurality of records each relating arespective logical identifier to one or more of a respective servicepoint location and personal information about a respective subscriber.13. The method defined in claim 12, wherein the online transaction iseffected over a network, the method further comprising assigning newlogical identifiers to various new end user equipment requesting accessto the network and updating the second database with (i) the new logicalidentifiers so assigned and (ii) for each of the new logicalidentifiers, one or more of a respective location of the correspondingnew end user equipment and personal information about a respectivesubscriber whose credentials were used by the corresponding new end userequipment to gain access to the network.
 14. The method defined in claim1, wherein the online transaction is effected over a network after theend user equipment has gained access thereto and wherein the evidentiaryinformation includes information pertaining to a subscriber whosecredentials were used by the end user equipment to gain access to thenetwork.
 15. The method defined in claim 14, wherein the informationpertaining to the subscriber includes personal information about thesubscriber.
 16. The method defined in claim 1, wherein the onlinetransaction is effected over a network after the end user equipment hasgained access thereto and wherein the evidentiary information includeslocation information.
 17. The method defined in claim 16, wherein thelocation information comprises a location of the end user equipment whenaccess to the network was gained.
 18. The method defined in claim 1,wherein the first identifier is a unique transaction identifiergenerated by an entity that is a member of a financial network.
 19. Themethod defined in claim 1, wherein said first identifier and said secondidentifier are received from an entity that is a member of a financialnetwork.
 20. The method defined in claim 1, wherein said firstidentifier and said second identifier are received from a merchant sitewith which the end user equipment interacts to effect the onlinetransaction.
 21. The method defined in claim 1, wherein the onlinetransaction involves at least one of an attempt to make a payment and anattempt to effect a fund transfer.
 22. The method defined in claim 1,wherein the online transaction involves at least one of an attempt toaccess secure online content and an attempt to access a virtual privatenetwork.
 23. A computer-readable medium comprising computer-readableprogram code which, when interpreted by a transaction management entity,causes the transaction management entity to execute a method, thecomputer-readable program code comprising: first computer-readableprogram code for causing the transaction management entity to beattentive to receipt of a first identifier associated with an onlinetransaction and a second identifier used by end user equipment involvedin the online transaction; second computer-readable program code forcausing the transaction management entity to obtain evidentiaryinformation pertaining to the end user equipment based on the secondidentifier; third computer-readable program code for causing thetransaction management entity to store in a database a record thatassociates the first identifier with the evidentiary information; andfourth computer-readable program code for causing the transactionmanagement entity to retrieve one of (i) the evidentiary information insaid record and (ii) the first identifier in response to a requestidentifying the other of (i) the evidentiary information in said recordand (ii) the first identifier.
 24. A system comprising: a transactionrecord database comprising a plurality of records, each of said recordsrelating a respective first identifier associated with an onlinetransaction to respective evidentiary information pertaining to end userequipment involved in the online transaction; and a transactionmanagement entity configured to respond to a request identifying one of(i) a given first identifier associated with a given online transactionand (ii) evidentiary information related by one of said records to agiven first identifier by retrieving the other of (i) the given firstidentifier and (ii) the evidentiary information related thereto.
 25. Thesystem defined in claim 24, the transaction management entity beingfurther configured to populate the transaction record database with arecord for the given first identifier further to receipt of the givenfirst identifier and a respective second identifier used by end userequipment involved in the given online transaction.
 26. The systemdefined in claim 25, wherein to populate the transaction record databasewith the record for the given first identifier, the transactionmanagement entity is configured to obtain said evidentiary informationby consulting a second database on a basis of the second identifier, thesecond database comprising a plurality of records each relating arespective identifier to respective evidentiary information.
 27. Thesystem defined in claim 26, wherein the given online transaction iseffected over a network after the end user equipment has gained accessthereto and wherein the evidentiary information includes informationpertaining to a subscriber whose credentials were used by the end userequipment involved in the given online transaction to gain access to thenetwork.
 28. The method defined in claim 26, wherein the given onlinetransaction is effected over a network after the end user equipment hasgained access thereto and wherein the evidentiary information includeslocation information indicative of a location of the end user equipmentinvolved in the given online transaction when access to the network wasgained.
 29. A method of investigating an online transaction associatedwith a transaction identifier, comprising: providing the transactionidentifier to a transaction management entity; obtaining from thetransaction management entity evidentiary information pertaining to theend user equipment involved in the online transaction associated withthe transaction identifier; and comparing the evidentiary information toinformation associated with a transaction object used to effect theonline transaction.
 30. The method defined in claim 29, furthercomprising: concluding that the online transaction was fraudulent orillegal when the comparing yields that the evidentiary information doesnot match the information associated with the transaction object used toeffect the online transaction.
 31. The method defined in claim 30,wherein the online transaction is effected over a network after the enduser equipment involved in the online transaction has gained accessthereto and wherein the evidentiary information includes informationpertaining to a subscriber whose credentials were used by the end userequipment involved in the online transaction to gain access to thenetwork.
 32. The method defined in claim 30, wherein the onlinetransaction is effected over a network after the end user equipmentinvolved in the online transaction has gained access thereto and whereinthe evidentiary information includes location information indicative ofa location of the end user equipment involved in the online transactionwhen access to the network was gained.
 33. A method of identifying asuspect potentially responsible for effecting an online transactionassociated with a transaction identifier, comprising: providing thetransaction identifier to a transaction management entity; obtainingfrom the transaction management entity evidentiary informationpertaining to the end user equipment involved in the online transactionassociated with the transaction identifier; and identifying as a suspecta party associated with the evidentiary information.
 34. A networkentity for participating in an online transaction taking place over anetwork, comprising: a memory; and a processing unit configured to:obtain a transaction identifier associated with an online transactionand a logical identifier associated with end user equipment involved inthe online transaction; store in said memory a record that relates saidtransaction identifier to said logical identifier; and transmit saidtransaction identifier and said logical identifier over the network toan entity responsible for storing a relationship between the transactionidentifier and evidentiary information pertaining to end user equipmentinvolved in said online transaction.
 35. The network entity defined inclaim 34, wherein the evidentiary information includes informationpertaining to a subscriber whose credentials were used by the end userequipment involved in the online transaction to gain access to thenetwork.
 36. The method defined in claim 34, wherein the evidentiaryinformation includes location information indicative of a location ofthe end user equipment involved in the online transaction when access tothe network was gained.